A problem encountered in automated testing of software applications is maintaining a set of test “scripts” when the changes are made to the software application. Scripts consist of computer instructions that are typically interpreted by the user interface as though there were typed directly from a keyboard. Thus, scripts are often distinguished from programs, because programs are converted permanently into binary executable files (i.e., zeros and ones) before they are run. Scripts remain in their original form and are interpreted command-by-command each time they are run. Testers create and maintain large sets of test scripts, often numbering in the thousands for a single application. These test scripts automate interactions with the application GUI, performing actions with GUI objects such as simulating the pushing of buttons or making menu selections.
Scripts are typically created in one of two ways. In the first, the tester performs the actions manually using a software recorder which keeps track of the actions performed and their context. The second is by manually creating the scripts, typically with a text editor, in a programming language, a scripting language, or some special-purpose language designed for test generation. Some testing systems support a hybrid of these, with an initial script created by demonstration and with enhancements to the script supported via manual editing.
Scripts created in these ways tend to be very dependent on the structure of a particular GUI. The script typically contains information on where to find each GUI element that is to be activated on replay. For example, a particular button labeled “submit” might be located in a section of the GUI with a section label “book flight”, which in turn is contained in a tab labeled “itinerary”. The script might contain an explicit description of such location information (e.g., “Activate itinerary→book flight→submit”) or an implicit description which is not viewable by the tester, but allows the test engine to locate the control on replay.
During an application's lifecycle, the GUI may undergo substantial changes—GUI elements may be moved to other parts of the application, their type may change (for example, a button may be converted into a menu item), or particular sequences of operations may be converted into different sequences that accomplish the same goals. These changes are examples of changes that may invalidate some or all of each script within a previously created library of test scripts.
Therefore a need exists for a method and system to facilitate the maintenance of libraries of scripts, particularly the maintenance of scripts in response to changes in the software application being tested so as to overcome the problems with the prior art as discussed above.